By analyzing the blame information on this pull request, we identified @edolstra, @cpages and @peti to be potential reviewers

I've noticed in a python package I created that it was unable to detect the timezone and then fell back to UTC. If I set the TZ variable in the systemd unit file, then it was working correctly.

So maybe it's because the python wrapper doesn't set it correctly and that's the real issue?

On my Arch Linux box, /etc/timezone is created, so I'm imagining there is other software out there that reads that file, so maybe for the sake of compatbility we should do this?

If I set the TZ variable in the systemd unit file, then it was working correctly.

Yes, you need to set $TZ in the systemd unit file, otherwise it won't be set.

So maybe it's because the python wrapper doesn't set it correctly and that's the real issue?

I don't believe that Python wrapper scripts ought to be responsible for the $TZ variable.

On my Arch Linux box, /etc/timezone is created, so I'm imagining there is other software out there that reads that file, so maybe for the sake of compatbility we should do this?

No, we want to avoid hidden global state as much as possible. The proper solution is to set $TZ in the systemd unit file that runs your script.

I agree with @peti.

I get your point about wanting to minimize global state, but we are already creating /etc/localtime which is "global timezone state" and this is just another way to represent the same thing for applications that for some reason do not use /etc/localtime. We are not polluting anything or adding any hidden depedencies.

Where exactly does Python use /etc/timezone? Grepping the Python 2 sources didn't turn up anything, and Python seems to detect my timezone fine:

>>> import time
>>> print time.tzname
('CET', 'CEST')

I noticed when doing #14262 that flexget wouldn't automatically pick up the timezone without the TZ variable being set (or the file being present).I don't know if this is a fault of flexget, one of its modules or python. I admittedly should have looked into that first before going ahead with this PR, but as mentioned, I noticed it on Arch Linux, so I simply assumed that /etc/timezone was simply missing. I'm happy regardless of which way this goes.

I propose we close this issue, as python core (3.5 tested locally) doesn't appear to use it, as tested via strace.